The Message Session Relay Protocol, MSRP, is a standard media plane protocol used between end-points through a communication network, for exchanging a series of related instant messages across an Internet Protocol, IP, network in the context of a rendezvous session. It is defined by the Internet Engineering Task Force, IETF, in Request For Comment, RFC 4975. The content in an instant message can be a text message, a Hypertext Transfer Protocol, HTML page, a file containing video clips, images, songs, or just a generic file. The content could also be related to sharing remote desktops or whiteboards.
MSRP is a text-based protocol that is carried on a media plane, over transport protocols such as Transport Control Protocol, TCP, IETF RFC 793, Stream Control Transmission Protocol, SCTP, IETF RFC 2690, Transport Layer Security, TLS over TCP, IETF RFC 2246, etc. In other words, any transport protocols that offer congestion control. As currently specified, MSRP does not impose a restriction on message size or content type.
MSRP Relays can also be used as defined by the IETF RFC 4976. MSRP Relays are used when one of the end-points is located behind a Network Address Translator, NAT, more specifically if the MSRP session has to span across multiple administrative domains. MSRP Relays are also used to support bulk messaging, and carry messages for a large number of MSRP sessions through a small number of inter-relay connections.
MSRP messages consist of requests and responses and not every MSRP request is answered by an MSRP response. MSRP defines methods and there are currently three specified methods:                SEND method for sending an instant message or file of any arbitrary length, etc.        REPORT method to provide message delivery notifications.        AUTH method used to authenticate an end-point with a Relay.        
MSRP cannot set up sessions on its own, and in order to establish an MSRP session between end-points, the MSRP session is negotiated via an external rendezvous mechanism. Typical rendezvous mechanism used to establish an MSRP session is Session Initiation Protocol, SIP, with Session Description Protocol, SDP offer/answer model. Other rendezvous protocols can of course be used and are not precluded. Currently, Session Initiation Protocol, SIP, IETF RFC 3261, and Session Description, SDP offer/answer, IETF RFC3264, are the only known standardized mechanism for establishing an MSRP session. SIP is an IETF standard protocol that allows for the establishment of interactive user sessions involving multimedia elements such as video, voice, chat, gaming, and virtual reality. It is also used to establish session based messaging sessions, i.e., MSRP sessions, for exchanging instant messages or files. The MSRP session parameters are exchanged in accordance with the SDP answer/offer model.
The following SDP attributes are exchanged between the end-points in an SDP offer/answer exchange via SIP in order to establish an MSRP session:                Accept Types: contains a list of media types that the end-point is willing to receive.        Wrapped Types: contains a list of media types that the end-point is willing to receive in an MSRP message with multipart content.        Max Size: that indicates the maximum number of octets of an MSRP message or the largest message the end-point is willing to receive. Max-size refers to the complete message and not the size of any one chunk. Senders should not exceed the max-size limit for any message sent in the resulting session.        Path: indicates a series of MSRP devices that must be visited by messages sent in the session, including the final end-point.        
Typically an originating end-point 100 hosting a SIP user agent sends to a remote end-point, also hosting a SIP user agent, a SIP INVITE that includes an SDP offer. The SDP offer comprises the message media type and the MSRP URI of the originating end-point 100 in the path attribute. If the remote end-point accepts the invitation, it responds with a 200 OK to acknowledge the choice of media and includes the receiving MSRP URI. At this point the MSRP session is set up and the end-points can start exchanging instant messages or files or the likes. The MSRP session is terminated when either end-point send a SIP BYE request.
Once the MSRP session is set up, the originating end-point 100 sends a SEND request to deliver a complete message, or if the message is very large, the originating end-point 100 could deliver the message in chunks using several SEND requests, where each SEND request contains one chunk of the overall message, a message ID corresponding to the whole message, a Byte-Range header field that identifies the portion of the message carried in the SEND request and the total size of the message. The remote end-point uses the received information to re-assemble the message and determines which chunks belong to which message. The remote end-point re-assembles the chunks into a complete message.
The SEND request may be answered by an MSRP 200 OK from a peer node or endpoint node and/or by a REPORT request from the end-point indicating successful delivery of the complete message. Incremental success REPORT requests may also be generated by the remote end-point as message chunks are received.
Currently, when a message is sent from an originating end-point 100 to a remote end-point, the originating end-point 100 decides on the MSRP chunk size based on for example its internal configuration. The MSRP Relay may also re-segment the MSRP message to a different chunk size than it was received. The re-segmenting performed at the MSRP Relay is typically based on internal configuration.
The determination of the chunk size does not take into account the remote end-point capabilities, the receiving network capabilities and the remote end-point mobility if it moves from a high capacity access network to a lower capacity access network or vice versa or if the network/link conditions in the remote end-point network has changed. This may lead to message chunks that may not be delivered or lack of optimization in delivery of the messages. Although MSRP is carried over a transport protocol that offers congestion control, the originating end-point has no indication as to the optimal chunk size that is acceptable to the remote end-point.